Multimedia calls and teleconferences, e.g., video calls, video chats, and Peer to Peer (P2P) file sharing sessions, using web applications, e.g., web browsers, are increasing in popularity. Web applications may initiate calls to each other based on World Wide Web Consortium (W3C) Web Real Time Communications (WebRTC) Application Programming Interfaces (APIs) using the same Call Signaling Protocol (CSP) without difficulty. However, a plurality of non-standardized CSP protocols exist and, consequently, some web applications may attempt WebRTC using conflicting CSPs, e.g., WebRTC Offer/Answer Protocol (ROAP), WebSocket (WS), Extensible Messaging and Presence Protocol (XMPP)/Jingle, Session Initiation Protocol (SIP), H.323, Media Gateway Control Protocol (MGCP), or CSPs specific to the communications web site. Conflicting CSPs typically results in an inability to engage in WebRTC communications.
As a result, applications with conflicting CSPs cannot initiate calls unless a previously agreed upon CSP is used for the call, which may be problematic in a number of circumstances. A WebRTC communications initiator (“caller”) may generally ensure CSP interoperability by using a CSP provided by a WebRTC communications recipient (“callee”) to call the callee. However, this may lead to phishing attacks in open web, since using a callee CSP may place the entire browser under the control of the callee web application and may render it difficult for the caller's web browser to enforce security norms. In a phishing context, a callee web application asks a caller to log into an XMPP server using the caller's Jabber Identifier (JID) and password. In a non-trustworthiness context, a government agency caller wants to alert a plurality of callees regarding an imminent natural disaster or other emergency. In such cases, the callees may be willing to use the CSP of the callers, but not vice versa.
Browser negotiation of CSPs using standard names, e.g., Uniform Resource Identifiers (URIs) or interface specifications, may not be desired for a variety of reasons. For example, standard names may not be desired because they require developing standard protocols, and developing standard protocols may take years to develop. Further, standard names may require extensive interoperability testing, namely, N×N pairwise coordinated number of tests, to verify functionality, and may ultimately only ensure interoperability to the extent of the tested cases. Consequently, an alternate solution may be preferred.